Method and apparatus for creation of an interface for constructing conversational policies

ABSTRACT

A method and apparatus for taking a visual or verbal representation of a conversational policy and translating the representation into an XML file. The XML file can then be output in one or more formats, such as code used in a policy, a Word version of the XML file, or a visual representation of the XML file.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is related to copending U.S. patent applicationSer. No. ______ (IBM Docket No. AUS920040545US1 entitled“Representations of Conversational Policies”) filed even date herewith.The above mentioned patent application is assigned to the assignee ofand share the same inventors as the present invention. The content ofthe cross referenced copending applications are hereby incorporatedherein by reference.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention is generally directed to network computingsystems. More specifically, the present invention is directed toproviding policies that govern transactions between two or more networkcomputer systems. Even more specifically, the present invention isdirected to an apparatus and method for creating an interface by whichconversation policies can be constructed for agents in a networkcomputing system.

2. Description of Related Art

In interactions between humans and an electronic business system orbetween two applications in an enterprise application system,participants, whether programs in the systems or humans, interact bysending messages to each other. These interactions can be brief, such asa simple query and answer, or they can be extended, such as in thenegotiation of a sale of products or services, where significantinformation, offers, and counter-offers can be exchanged. U.S. PatentApplication 20030204405, published Oct. 30, 2003, which is owned by theassignee of the current application and is hereby incorporated byreference, discloses a means for providing modular conversationpolicies. This provides a structure in which policies can be brought infrom an outside source and modified to meet a specific business system.

As the use of such conversational policies becomes more common, itbecomes increasingly desirable to be able to write new policies and tomodify old policies. The policies are currently created in a form ofextensible markup language (XML), a language that uses tags. However,the rigid structure of an XML tree does not lend itself to error-freecoding. A different manner of writing policies is needed.

SUMMARY OF THE INVENTION

The present invention provides a method and apparatus that can take avisual or verbal representation of a conversational policy and translatethe visual or verbal representation into an XML file. The XML file canthen be output in one or more formats, such as code used in a policy, aWord version of the XML file, or a Visio representation of the XML file.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed characteristic of the invention are setforth in the appended claims. The invention itself, however, as well asa preferred mode of use, further objectives and advantages thereof, willbest be understood by reference to the following detailed description ofan illustrative embodiment when read in conjunction with theaccompanying drawings, wherein:

FIG. 1 depicts a network of data processing systems in which the presentinvention may be implemented.

FIG. 2 depicts a block diagram of a data processing system that may beimplemented as a server in which the present invention may beimplemented.

FIG. 3 graphically depicts the three parts of the inventive structureand method, according to an embodiment of the invention.

FIGS. 4A and 4B depict a flowchart of the action of the identificationinterface of FIG. 3 according to an exemplary embodiment of theinvention.

FIGS. 5A and 5B depict two representations of a single conversationalpolicy that might be input to an embodiment of the disclosed programs.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Hardware

With reference now to the figures, FIG. 1 depicts a pictorialrepresentation of a network of data processing systems in which thepresent invention may be implemented. Network data processing system 100is a network of computers in which the present invention may beimplemented. Network data processing system 100 contains a network 102,which is the medium used to provide communications links between variousdevices and computers connected together within network data processingsystem 100. Network 102 may include connections, such as wire, wirelesscommunication links, or fiber optic cables.

In the depicted example, server 104 is connected to network 102 alongwith storage unit 106. In addition, clients 108, 110, and 112 areconnected to network 102. These clients 108, 110, and 112 may be, forexample, personal computers or network computers. In the depictedexample, server 104 provides data, such as boot files, operating systemimages, and applications to clients 108-112. Clients 108, 110, and 112are clients to server 104. Network data processing system 100 mayinclude additional servers, clients, and other devices not shown. In thedepicted example, network data processing system 100 is the Internetwith network 102 representing a worldwide collection of networks andgateways that use the Transmission Control Protocol/Internet Protocol(TCP/IP) suite of protocols to communicate with one another. At theheart of the Internet is a backbone of high-speed data communicationlines between major nodes or host computers, consisting of thousands ofcommercial, government, educational and other computer systems thatroute data and messages. Of course, network data processing system 100also may be implemented as a number of different types of networks, suchas for example, an intranet, a local area network (LAN), or a wide areanetwork (WAN). FIG. 1 is intended as an example, and not as anarchitectural limitation for the present invention.

Referring to FIG. 2, a block diagram of a data processing system thatmay be implemented as a server, such as server 104 in FIG. 1, isdepicted in accordance with a preferred embodiment of the presentinvention. Data processing system 200 may be a symmetric multiprocessor(SMP) system including a plurality of processors 202 and 204 connectedto system bus 206. Alternatively, a single processor system may beemployed. Also connected to system bus 206 is memory controller/cache208, which provides an interface to local memory 209. I/O bus bridge 210is connected to system bus 206 and provides an interface to I/O bus 212.Memory controller/cache 208 and I/O bus bridge 210 may be integrated asdepicted.

Peripheral component interconnect (PCI) bus bridge 214 connected to I/Obus 212 provides an interface to PCI local bus 216. A number of modemsmay be connected to PCI local bus 216. Typical PCI bus implementationswill support four PCI expansion slots or add-in connectors.Communications links to clients 108-112 in FIG. 1 may be providedthrough modem 218 and network adapter 220 connected to PCI local bus 216through add-in connectors.

Additional PCI bus bridges 222 and 224 provide interfaces for additionalPCI local buses 226 and 228, from which additional modems or networkadapters may be supported. In this manner, data processing system 200allows connections to multiple network computers. A memory-mappedgraphics adapter 230 and hard disk 232 may also be connected to I/O bus212 as depicted, either directly or indirectly.

Those of ordinary skill in the art will appreciate that the hardwaredepicted in FIG. 2 may vary. For example, other peripheral devices, suchas optical disk drives and the like, also may be used in addition to orin place of the hardware depicted. The depicted example is not meant toimply architectural limitations with respect to the present invention.

The data processing system depicted in FIG. 2 may be, for example, anIBM eServer pSeries system, a product of International Business MachinesCorporation in Armonk, N.Y., running the Advanced Interactive Executive(AIX) operating system or LINUX operating system.

Overview of Modules

With reference now to FIG. 3, a graphic representation of the three mainparts of the inventive structure and method are shown according to anillustrative embodiment of the invention. On the left-hand side of thisfigure, three possible input files are shown: file 302 is in Adobe®Acrobat®, file 304 is in Microsoft® Powerpoint®, and file 306 is in IBM®Rational Rose®, a software development platform. Notably, these threeinput formats are only representative of the types of input that can bereceived by the inventive interface; many other types of input can alsobe used, such as text description or other graphic representations. Theidea is that the user can work in whatever format they feel mostcomfortable with, while the inventive software will handle the interfaceto the required format transparently.

Identity interface 308 takes an input file, such as files 302, 304, 306and identifies objects and descriptions that exist in the input files,using either identification provided in the files or by querying theuser. Once identity interface 308 is completed, mapping engine 310performs mapping between policy objects that have been identified andthe xml structures that represent them. A table holds the entries andthe sections of code that will be saved to the xml tree. Finally, outputgenerator 312 translates the prepared xml tree into a desired format.Several possible outputs are shown in this figure: file 314 is inConversation Policy XML (CPXML), file 316 is a text description of thepolicy, and file 318 is a visual representation of the policy. Like theinput, the output format can be as varied as the input, such that oncethe policy is created, it can be viewed in whatever format is consideredmost appropriate to the user's needs, whether that need is to executethe conversational policy, to be able to view it for modification, togive a presentation of the policy, etc. The sections of the inventiveinterface will be discussed in greater detail below. It is noted thatwhile these modules are discussed as if they are three separate modules,the actual boundaries between the modules need not be as discussed, aslong as the capabilities are present.

Modules

Identity Interface 308 has the job of identifying each item in theconversation policy. Exemplary modules designed to serve this purposewill share the same recognition algorithm, but may vary in thespecifics, for example, of how to recognize a given shape in thespecific format. The identity interface must accomplish several tasks:

(a) it must distinguish between a state and an action to move betweenthe states,

(b) it must identify the starting state,

(c) for every state, it must identify every action that is possible inorder to leave the state, and

(d) for every action, it must identify the beginning state, the endingstate, and the identity of the entity performing the action.

With reference now to FIG. 4A, a flowchart of the identity interface 308is discussed according to an exemplary embodiment of the invention. Theflowchart starts with a determination whether or not to use the standardidentification table provided (step 410). This table identifies themeaning of each figure or shape in the conversational policy. The tableis generally initialized with standard shapes and their given meaning,but the user may also define their own meanings and even new shapes, sothat they can work with whatever symbols seem most intuitive to them.Thus, if the user chooses to use the existing identification table, theflow goes to load identification table (step 412). If the user wants todefine their own symbols and/or meanings, the flow moves to a session inwhich the program queries the user and creates a new identificationtable (step 414). Although not specifically shown in this figure, theuser can be allowed to save their definitions such that they can be usedat a later time. Once the identification table is ready, the identityinterface locates the initial state where the conversation begins (step416). For graphical representations, the initial state will generally belocated in the top left-hand corner. Alternatively, the user can beasked to identify the initial state. The program then determines if theelement is described in the table or not (step 418). If the element ispresent in the table, the program looks up the identification of thiselement (step 420), otherwise, the program will query the user about theidentification of the element, then will store the new shape and meaningin the identification table (step 422). The identity interface can thendetermine if the element is a state or an action (step 424). If theelement is a state, the name of the state is stored, then the number ofactions that cause movement out of this state are determined and saved(step 426); if the element is an action, the program stores the name ofthe action, the state where the action begins, the state where theaction ends, and the entity performing the action (step 428). After theappropriate information is stored for the current element, a check ismade to see if there are more elements to be identified (step 430). Ifadditional elements remain, the program moves to identify the nextelement (step 432) and return to process that element (step 418); if allelements have been identified, identity interface continues in FIG. 4B.

With reference now to FIG. 4B, the identity interface organizes theinformation it has identified, setting up a blank table into which theinformation will be organized (step 440). Each entry in the table willhave at least the following four fields (a) beginning state, (b) action,(c) ending state, and (d) performer. The identity interface then goesthrough the information it has identified and searches to find the firstidentified state (step 442). For each action that can be taken to moveout of that state, an entry in the table is created (step 444) and thename of the current state is stored in the beginning state field (a).For example, if the current state is a determination if a condition istrue or false, two actions will move the conversation out of that state:an answer of ‘true’ or an answer of ‘false’. In this instance, twoentries in the table would be created with a beginning state of‘Determine Condition’: one with a ‘true’ message and the other having a‘false’ message. If a state is a termination point for the conversation,there will not be any actions that move the conversation out of thatstate. In this instance, a single entry is created in the table, withthe state name stored in the beginning state field (a), but no otherfields filled.

Once an entry for a state is fully created, the mapping enginedetermines if there is a next state (step 446). If the answer is ‘yes’,the next state is located (step 448) and the mapping engine returns tocreate the proper number of new table entries (step 444); otherwise, themapping engine returns to the beginning of the file and searches for thefirst action (step 450).

When an action is located, it will have a beginning state and an endingstate, as previously determined. The identity interface 310 locates thetable entry for the corresponding beginning state and action, and thenfills in the ending state and the performer (step 452). The mappingengine 310 then looks to see if there are any additional actions to beentered (step 454). If there are, the mapping engine locates the nextaction (step 456) and returns to fill in the next table entry (step452); otherwise, the mapping engine has completed forming the table andterminates.

In an alternate embodiment, the identity interface can create the tableby a single pass through the information collected. In this embodiment,the identity interface creates an empty table structure. For each actionshown in the input, the program creates an entry in the table thatcontains the four fields listed above. A separate entry for a state iscreated only for the beginning state, which must be identified as such,and for terminal states, which have no actions leading out of them.Preferably, once all entries are made, the table should be sorted sothat all actions associated with a given step are listed together forease of translation into XML.

Notably, the identification process is not limited to objects, such asshapes, but can apply the identification to descriptions or patterns.For example, a user might describe a conversation policy in words thatcould then be identified and mapped. The ability to learn meanings andto recognize them later makes this program very flexible.

Once the identity interface has created the disclosed table, the mappingengine 310 will create the appropriate coding for an XML tree for theconversation. This is a fairly straightforward translation and involvesmoving through the table, creating and assembling coding fragments.Because XML is a very flexible language, the ‘universe’ that the codingrepresents must be defined in a schema for conversation policies, whichforms an XML fragment for the tree. XML requires that (a) the overallconversation be given a name by which it can be addressed, (b) eachparticipant in a dialog be defined as a role, (c) each state mustcontain a unique name and must contain any necessary information toperform the needed actions of the role, and (d) each possible transitionfrom that state must be described. Since the states and actions havealready been assembled into a table, the inventive program can routinelyconvert them to an XML tree. Where further clarification is needed, theuser can be queried for information.

The final portion of the innovative method is the output generator 312.The output generator 312 can take the XML tree created by mapping engine310 and convert this to the form desired by the user. This can be an XMLfile, which can be checked against company policies and validated, thenexecuted. It can also be a Word® document, showing the XML file in aformat more easily readable by humans. The output can also be providedin a graphical format. For instance, after a conversational policy iscreated, a user may wish to provide a presentation of the idea; they canthen convert the XML tree to an output format compatible with apresentation, such as Microsoft® Powerpoint®.

EXAMPLE

In order to clarify the idea disclosed, an exemplary conversation policyis shown as an embodiment of the inventive method and apparatus convertsit into XML.

With reference now to FIG. 5A, an exemplary conversation policy isgraphically shown. In this example, the conversation is between a buyerand a seller and is in regard to the availability and purchase of aproduct or service. Conversations between humans and machines or betweentwo machines are inherently stateful, i.e. the content of any earliermessages constrains or partially determines the content of possiblemessages later on, so that at any given point, the conversation iseither in a given state or in transition between two states. In theconvention used by this figure, a state is shown by a rectangle, thelower half of which is hatched, while the upper half contains the nameof the state and a circled letter indicating the type of state: aregular state contains an S in the circle, a child state contains a C,and a response state contains an R. As the name implies, a child statecan be a separate conversation policy that is called by the currentpolicy, which will return a response chosen from a set of allowableresponses. The types of actions that are used to move between statesare: sending a message SM, giving a response from a child state CR, orincurring a timeout TO. The conversation policy begins with the ReadyState 510. There is only one way to move out of the Ready State 510,i.e., the buyer sends message 522 querying the availability of an itemor service. When a message of this type is sent and received, theconversation moves to the Querying State 512. While in the QueryingState 512, the seller is checking to see if the requested item orservice can be supplied. The response will be to provide one of tworeplies: yes or no. If the product is not available, the seller sends a‘No’ message 530, which moves the conversation to the ‘No Deal’ state520, which completes this conversation. It is, of course, possible tostart another conversation by querying the availability of anotherproduct, but the original conversation has reached a conclusion.Alternatively, if the item is available, sending a ‘Yes’ message 526moves the conversation to the ‘Is Available’ state 514. According to theconversation policy shown, three responses are available and thus, threeroutes exist out of this state. In the first response, the buyer onlywanted information at this time, so they send a “Bye” message 532, whichmoves the conversation to the “No Deal” state 520. In a second response,the buyer shows interest in pursuing the transaction, sending a “LoadHaggle” message 528, which moves the conversation to the ‘In Haggle’state 516, which is a child state. A final way to leave the ‘IsAvailable’ state is for the buyer to give no response, so that thetransaction incurs a timeout 524 and returns to the Ready state 510. Forconversations that have reached the ‘In Haggle’ state 516, this statewill be maintained until either an agreement is reached between the twoparties or else one party determines that a mutually satisfactoryconclusion cannot be reached. If the In Haggle state 516 ends with aresponse of ‘Accepted’ 536, the conversation moves to the ‘Deal Made’state 518 and concludes. Otherwise, a ‘Cancelled’ response 534 is sentand the conversation moves to the ‘No Deal’ state 520 and concludes.

This same conversation policy can also be represented in a somewhatdifferent manner, depending on the user and the visual system used torepresent the policy. FIG. 5B depicts an alternate way to represent thesame conversation policy. In this figure, the various states are shownby ovals, with the events that prompt a change of state shown as arrows.Again, the conversation initially starts from the ‘Ready’ state 550 andfrom this state the only input that can cause movement is a ‘QueryProduct’ 552, which moves the conversation to a ‘Querying’ state 554. Ifthe product is not available, a ‘No’ response 556 moves the conversationto the ‘No Deal’ state 574. If the product is available, a ‘Yes’ message558 moves the conversation to the ‘Is Available’ state 560. From the ‘IsAvailable’ state 560, the conversation can move in three directions: anavailable timeout 562 returns the conversation to a ‘Ready’ state 550, a‘Bye’ message 568 from the buyer moves the conversation to a ‘No Deal’state 574, or a ‘Load Haggle’ message 564 from the buyer moves theconversation to a ‘In Haggle’ state 566. If the conversation moves tothe ‘In Haggle’ state, the conversation will either end with a returnmessage of ‘Cancelled’ 570, which ends in a ‘No Deal’ state 574 or‘Accepted’ 572, which ends in a ‘Deal Made’ message 576.

For either of the two FIGS. 5A and 5B, identity interface 308 identifieseach item and description represented in the conversation policy, usinga table that identifies the meaning of the shapes represented. Once eachstate and action has been identified the identity interface will createa table such as the one shown in Table 1. TABLE 1 Beginning Ending StateAction State Performer Ready Query product Querying Buyer messageQuerying Yes message IsAvailable Seller Querying No message NoDealSeller IsAvailable Timeout Ready Timeout IsAvailable LoadHaggle InHaggleBuyer message IsAvailable Bye NoDeal Buyer InHaggle Accepted DealMadeChild Response InHaggle Cancelled NoDeal Child Response DealMade NoDeal

Mapping engine 310 next takes the information in Table 1 and createsappropriate coding fragments to go with each element. For example, theroles can be defined as a buyer and a seller with coding such as,<Roles>  <Role>Buyer</Role>  </Roles>  <Roles>  <Role>Seller</Role></Roles>Each state will have its name defined and the transitions out of itcoded,

-   -   <State Stateld=“Name”> . . . </State>

The information needed to describe this state is described in code, suchas the transitions out of this state. If the state is a child state, theappropriate child must be encoded. Shown below is a printout of an XMLfile created from Table 1. <ConversationPolicyxmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:noNamespaceSchemaLocation=“ConversationPolicy2.0.xsd”> <Name>BuyStuff</Name>  <Roles>   <Role>Buyer</Role>  </Roles>  <Roles>  <Role>Seller</Role>  </Roles>  <InitialState>  <IniStateName>Ready</IniStateName>  </InitialState>  <StateStateId=“Ready”>   <SendMessageTransition TransitionName=“QueryProduct”>  <Target>Querying</Target>   <Sender>Buyer</Sender>  <Event>SendMessage</Event>   <Message>    <Encoding>java</Encoding>   <Schema>com.ibm.conversation.BuySellCA.ProductQueryMessageSchema</Schema>  </Message>   </SendMessageTransition>  </State>  <StateStateId=“Querying”>   <SendMessageTransition TransitionName=“No”>  <Target>NoDeal</Target>   <Sender>Seller</Sender>  <Event>SendMessage</Event>    <Message>    <Encoding>java</Encoding>   <Schema>com.ibm.conversation.BuySellCA.NoMessageSchema</Schema>  </Message>   </SendMessageTransition>   <SendMessageTransitionTransitionName=“Yes”>   <Target>IsAvailable</Target>  <Sender>Seller</Sender>   <Event>SendMessage</Event>    <Message>   <Encoding>java</Encoding>   <Schema>com.ibm.conversation.BuySellCA.YesMessageSchema</Schema>  </Message>   </SendMessageTransition>  </State>  <StateStateId=“IsAvailable”>   <Timeout>P5M</Timeout>   <TimeoutTransitionTransitionName=“AvailableTimout”>   <Target>Ready</Target>  <Event>OnTimeout</Event>   </TimeoutTransition>  <SendMessageTransition TransitionName=“LoadHaggle”>  <Target>InHaggle</Target>   <Sender>Buyer</Sender>  <Event>SendMessage</Event>    <Message>    <Encoding>java</Encoding>   <Schema>com.ibm.conversation.BuySellCA.LoadHaggleMessageSchema</Schema>   </Message>   </SendMessageTransition>   <SendMessageTransitionTransitionName=“Bye”>   <Target>NoDeal</Target>   <Sender>Buyer</Sender>  <Event>SendMessage</Event>    <Message>    <Encoding>java</Encoding>   <Schema>com.ibm.conversation.BuySellCA.ByeMessageSchema</Schema>   </Message>   </SendMessageTransition>  </State>  <StateStateId=“InHaggle”>   <LoadChild>   <Policy>buysellhaggle.cpxml</Policy>    <Rolemap>    <RolemapElement>    <Parent>Buyer</Parent>     <Child>Initiator</Child>   </RolemapElement>    <RolemapElement>     <Parent>Seller</Parent>    <Child>Responder</Child>    </RolemapElement>    </Rolemap>  </LoadChild>   <ChildReturnTransition TransitionName=“Accepted”>  <Target>DealMade</Target>   <Event>ChildReturn</Event>  <ChildReturn>Accepted</ChildReturn>   </ChildReturnTransition>  <ChildReturnTransition TransitionName=“Cancelled”>  <Target>NoDeal</Target>   <Event>ChildReturn</Event>  <ChildReturn>Cancelled</ChildReturn>   </ChildReturnTransition> </State>  <State StateId=“NoDeal”>   <Return>NoDeal</Return>  </State> <State StateId=“DealMade”>   <Return>DealMade</Return>  </State></ConversationPolicy>

Finally, the XML tree, once created by the mapping engine 310, can beplaced in one of several formats by the output generator. The listingabove is the XML file in Word format, easily read and comprehended by auser. In XML format, the coding can be input to a machine forvalidation. Other formats can also be produced.

Using the disclosed invention, a conversational policy can be describedin a visual format that is easy for users to comprehend and manipulate.The transformation into machine-usable coding is performed by machine,removing the tediousness of the process and avoiding human errors in theactual coding process. Since a number of visual or written formats canbe utilized, the user is free to find the format that is intuitivelybest for them without sacrificing quality in the finished product.

It is important to note that while the present invention has beendescribed in the context of a fully functioning data processing system,those of ordinary skill in the art will appreciate that the processes ofthe present invention are capable of being distributed in the form of acomputer readable medium of instructions and a variety of forms and thatthe present invention applies equally regardless of the particular typeof signal bearing media actually used to carry out the distribution.Examples of computer readable media include recordable-type media, suchas a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, andtransmission-type media, such as digital and analog communicationslinks, wired or wireless communications links using transmission forms,such as, for example, radio frequency and light wave transmissions. Thecomputer readable media may take the form of coded formats that aredecoded for actual use in a particular data processing system.

The description of the present invention has been presented for purposesof illustration and description, and is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the art. Theembodiment was chosen and described in order to best explain theprinciples of the invention, the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

1. A method of constructing a conversation policy, said method comprising the computer-performed steps of: receiving a conversational policy that has been created in a graphical or verbal form; identifying elements of said conversational policy and associating meanings with said elements; identifying relationships between said elements; and using said elements, said meanings associated with said elements, and said relationships to construct a file in an extensible machine language that describes the conversational policy.
 2. The method of claim 1, further comprising converting said file into a format other than an extensible machine language.
 3. The method of claim 1, wherein said conversational policy is received in a format created by a program chosen from a group consisting of a word processor, a presentation graphics program, a drawing program, and a software development platform.
 4. The method of claim 1, wherein said identifying elements step uses a table of standard elements having associated meanings.
 5. The method of claim 1, wherein said identifying elements step dialogs with a user to create a table of user elements having associated meanings.
 6. The method of claim 1, wherein said identifying elements step recognizes a first shape as representing a state and a second shape as representing a message that moves said conversation policy from a first state to a second state.
 7. The method of claim 1, wherein said identifying elements step recognizes a first pattern as representing a state and a second pattern as representing a message that moves said conversation policy from a first state to a second state.
 8. A computer system, comprising: a processor, connected to receive input and to write output; memory, connected to said processor; and a set of instructions stored in said memory and connected to be executed by said processor, said set of instructions containing first instructions for receiving a conversational policy that has been created in a graphical or verbal form, second instructions for identifying elements of said conversational policy and associating meanings with said elements, third instructions for identifying relationships between said elements, and fourth instructions for using said elements, said meanings associated with said elements, and said relationships to construct a file in an extensible machine language that describes the conversational policy.
 9. The computer system of claim 8, wherein said set of instructions further comprises converting said file into a format other than an extensible machine language.
 10. The computer system of claim 8, wherein said first instructions receive said conversational policy in a format created by a program chosen from a group consisting of a word processor, a presentation graphics program, a drawing program, and a software development platform.
 11. The computer system of claim 8, wherein said second instructions dialog with a user to create a table of user elements having associated meanings.
 12. The computer system of claim 8, wherein said second instructions recognize a first shape as representing a state and a second shape as representing a message that moves said conversation policy from a first state to a second state.
 13. The computer system of claim 8, wherein said second instructions recognize a first pattern as representing a state and a second pattern as representing a message that moves said conversation policy from a first state to a second state.
 14. A computer program product on a computer-readable media, said computer program product comprising: first instructions for receiving a conversational policy that has been created in a graphical or verbal form, second instructions for identifying elements of said conversational policy and associating meanings with said elements, third instructions for identifying relationships between said elements, and fourth instructions for using said elements, said meanings associated with said elements, and said relationships to construct a file in an extensible machine language that describes the conversational policy.
 15. The computer program product of claim 14, wherein said set of instructions further comprises converting said file into a format other than an extensible machine language.
 16. The computer program product of claim 14, wherein said first instructions receive said conversational policy in a format created by a program chosen from a group consisting of a word processor, a presentation graphics program, a drawing program, and a software development platform.
 17. The computer program product of claim 14, wherein said second instructions use a table of standard elements having associated meanings.
 18. The computer program product of claim 14, wherein said second instructions dialog with a user to create a table of user elements having associated meanings.
 19. The computer program product of claim 14, wherein said second instructions recognize a first shape as representing a state and a second shape as representing a message that moves said conversation policy from a first state to a second state.
 20. The computer program product of claim 14, wherein said second instructions recognize a first pattern as representing a state and a second pattern as representing a message that moves said conversation policy from a first state to a second state. 